\section{Development Process}

The language and the interpreter were developed basically in a waterfall model.

\subsection{Designing the Language}

In the beginning, we whimmed several domains for our language, including board game, network troubleshooting, etc. Finally the board game was chosen for its possible taste of delight. Thus the role of language guru was assigned to \textbf{Yi}, who is most familiar with board games in our group.\\

A brainstorm was exercised to determine the design of the language, the concept event and the design of data structures like container were brought up. However, the design didn't converge until very late. The argument between the language guru and the project manager made it a rather tough period -- the language guru had new ideas about the language, however the project manager want to make sure the project can be delivered in time.\\

Modifications to the grammer of the language continued before we had run our first Tactics program. It is very hard to have a sight far enough to reach the very detail of the implementation and the language.

\subsection{Implementing the Interpreter}

The implementation begins after we have the first grammer sheet. However, it was very slow in the beginning since we still have some disagreement on details about the language, and what we are to implement -- an interpreter, translator, or compiler?\\

Our system architect \textbf{Chenguang} investigated the basic architect to implement a translator and the one to implement an interpreter, and together with me made a decision on the architect of our interpreter or translator -- to build a abstract syntax tree using \texttt{yacc} and then analyze the tree to either interpret or translate -- though we intended to implement a translator.\\

I built the \texttt{yacc} rules, designed the data structures of the abstract syntax tree and found that, in our design, some necessary information (e.g. size of an enum-indexed array) cannot be retrieved when analyzing the the source code bottom-up, and thus decided to have a second analyzing phase which is called \textit{validation} and carries out a top-down analysis and validates the semantic of the abstract syntax tree. Some sample Tactics code were created to test our abstract syntax tree and validation, and we could early make sure this front-end works well. During this process, the grammar was updated several times for we found inconvenience and conflicts in analyzing the abstract syntax tree.\\

For technical reasons, we turned from implementing a translator (from Tactics to C) to implementing an intepreter, just before we go ahead too much on the translator way. Our whole team studied the type inference and type compatible issues and wrote the intepretation code. \textbf{Shu} and \textbf{Bo} wrote the underlying container implementation, \textbf{Chenguang} wrote the enumeration implementation, \textbf{Yi} wrote the statement execution and expression evaluation, and I implemented the construction and validation of the abstract syntax tree.

\section{Roles and Responsibilites}

\begin{itemize}

\begin{item}
Minglei Wang, Project Manager
\begin{itemize}
\item{Take trade-offs between ease of delivery and language functionality,}
\item{Organize project meeting and synchronize understanding of the language,}
\item{Lead the review of all sumbitted code,}
\item{Write code.}
\end{itemize}
\end{item}

\begin{item}
Yi Lin, Language Guru
\begin{itemize}
\item{Design the functionality of the language,}
\item{Write code.}
\end{itemize}
\end{item}

\begin{item}
Chenguang Lu, System Architect
\begin{itemize}
\item{Design the high-level architecture of the interpreter,}
\item{Write code.}
\end{itemize}
\end{item}

\begin{item}
Shu Yang, System Integrator
\begin{itemize}
\item{Set up code repository and track bugs,}
\item{Set up development environment,}
\item{Write code.}
\end{itemize}
\end{item}

\begin{item}
Bo Li, Test and Validation
\begin{itemize}
\item{Write sample Tactics code,}
\item{Do test plan and write test cases,}
\item{Write code.}
\end{itemize}
\end{item}

\end{itemize}

\section{Implementation Style}

We basically follow the Linux kernel coding style since 4 out of 5 team members took Operating Systems I last semester and are familiar with it, and I think it has a very high readability. However, our style are very relaxed comparing with the Linux standard considering the capability of our team members.

\subsection{Indentation}

Indentation are purely tabs and each tab takes 8 spaces. Whitespaces are allowed in the end of indentation if we need to adjust the placement to a non-regulaer position, e.g. adjusting long conditions joined by \texttt{||} in a \texttt{if} statement.

\subsection{Spaces}

Spaces are required around any binary or trinary operators. There is no restriction on unary operators. This rule can be broken when "grouping" items together by eliminating spaces will show its logical relationship, e.g. \texttt{if (x+5 > y+6)}.\\

There should be no space before an opening parenthesis if it's a function call, otherwise a whitespace is used, e.g. \texttt{if (true) printf("\%d", i);}.

\subsection{Braces}

The style in \texttt{K\&R C} is used. In most cases, the opening brace is put last on the line, and the closing brace is the closing brace on the first column. The closing brace is always on a line of its own, except the one in a \texttt{do..while} statement or \texttt{if..else} statement. There are no restriction on whether or not put braces around a single statement.
\begin{verbatim}
if (foo) {
        bar();
}
\end{verbatim}

However, in implementing a function, both the opening and closing brace are put on the first column.
\begin{verbatim}
int foo (int bar)
{
        return bar;
}
\end{verbatim}

\subsection{Naming}

Two naming styles are accepted: \texttt{thisone} and \texttt{this\_one}. Usually a word is not represented in a abbreviation, with an exception that really frequently used words in a particular context receive a single letter abbreviation, most cases are in the data structures of the abstract syntax tree, e.g. \texttt{x} for expression, \texttt{s} for statement.

\section{Timeline and Project Log}

\begin{tabular}{c p{14cm}}
Feb 16	& \textbf{Meeting}: Language domain (board game) and feature (event, container)\\
Feb 23	& Language White Paper due\\
Mar 16	& \textbf{Meeting}: Grammar draft\\
Mar 23	& Language Tutorial due, Language Reference Manual due\\
Apr 21	& \textbf{Meeting}: Grammar and yacc rules, decided to make a translator\\
Apr 28	& \textbf{Meeting}: Working abstract syntax tree\\
May 3	& \textbf{Meeting}: Working validated internal (intermediate) representation, change to make an interpreter\\
May 5	& \textbf{Meeting}: Working expression evaluation and statement execution\\
May 6	& \textbf{Meeting}: (Buggy) working interpreter, validating and testing\\
May 8	& Final Report (Draft) due\\
May 10	& Working Compilier, Final Report due\\
\end{tabular}
